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ABSTRACT 

The United States Marine Corps is exploring the concepts of Operational 
Maneuver From the Sea (OMFTS) and Ship-To-Objective Maneuver (STOM) as 
methods for employment of maritime forces in the future. At the same time, the 
Department of Defense (DoD) is pursuing the acquisition of the Joint Tactical Radio 
System (JTRS), a multi-band, multi-channel, multi-mode family of radios, designed to 
form self-organizing, self-healing communications networks. The JTRS will have to 
support Marine forces in combat at long distances from the forces’ support and higher 
headquarters units. This extended range will require the use of relay radios in order to 
maintain connectivity between the attacking force and its support. 

This thesis explores the relay station bandwidth requirements to support Marine 
forces. The question is analyzed through the use of a discrete-event simulation written in 
Java, which models the behavior of a JTRS network in a STOM scenario. Quality of 
service of the communication network is measured by timely delivery of messages. 

The results of the simulation indicate that the JTRS network performance is 
insensitive to relay station bandwidth. Rather, the subordinate headquarters involved in 
the scenario were the most overloaded nodes in the network. 
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DISCLAIMER 



The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Defense or the U.S. Government. 

The reader is cautioned that computer programs developed in this research may 
not have been exercised for all cases of interest. While every effort has been made, 
within the time available, to ensure that the programs are free of computational and logic 
errors, they cannot be considered validated. Any application of these programs without 
additional verification is at the risk of the user. 
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EXECUTIVE SUMMARY 



The United States Marine Corps is exploring the concepts of Operational 
Maneuver From the Sea (OMFTS) and Ship-To-Objective Maneuver (STOM) as 
methods for employment of maritime forces in the future. At the same time the 
Department of Defense (DoD) is pursuing the acquisition of the Joint Tactical Radio 
System (JTRS), a multi-band, multi-channel, multi-mode family of radios, designed to 
form self-organizing, self-healing communications networks. The JTRS offers great 
advances in communication technologies for use in OMFTS. 

JTRS is currently in Phase 1, Program Definition and Risk Reduction (PDRR), of 
the acquisition process. This phase is intended to describe the exact requirements for a 
system and to identify low risk paths to reach those requirements. The bandwidth 
requirements of the relay suite for the JTRS have not yet been specified. It is critical to 
correctly specify these requirements because the JTRS will support Marine forces 
involved in OMFTS and STOM at long distances from the forces’ support and higher 
headquarters units. This extended range will require the extensive use of relay radios in 
order to maintain connectivity between the attacking force and its support. 

This thesis explores the relay station bandwidth requirements to support Marine 
forces in STOM. The question is analyzed through the use of a discrete- event simulation 
written in Java, which models the behavior of a JTRS network in a STOM scenario. 

The simulation developed moves JTRS units around a simulated battlefield. As 
each JTRS moves through the simulation it generates messages. The arrival of messages 
is viewed as a Poisson process. The frequency and priority of these messages changes 
when the tactical situation of the JTRS changes. 

Generated messages then pass through the JTRS network until they reach their 
intended recipient. Messages flow through the network following a few simple rules. 
The two most important of these rules are: a radio in direct contact with the target of a 
message will always send it to the target, and a radio not in contact with the message’s 
target will send the message to a randomly selected radio with which it is in contact 



XIX 



When a message is generated its priority determines how long the system has to 
deliver the message to its recipient. A message that is not delivered in less than that time 
is considered late. The characteristic of JTRS network selected for evaluation is timely 
delivery of messages. This characteristic is measured by a penalty function that penalizes 
the system for late delivery of messages. The penalty for lateness of a particular message 
is weighted by the priority of that message. 

The scenario used in the simulation is an example of STOM against two 
Objectives. The main Objective is located 125 miles inland and is attacked by two 
battalions. A supporting attack of one battalion is sent against another objective that is 30 
nautical miles inland. The regimental headquarters remains aboard amphibious shipping, 
located 50 nautical miles from shore. The range across which the attacking force must 
maintain communication is up to 175 nautical miles. 

The simulation was run for 20 iterations each under several relay bandwidth 
capacities. The results of the simulation indicate that the JTRS network performance is 
insensitive to relay station bandwidth. It is possible that the result may stem from the 
simplistic rules that the model uses to route messages through the network. Although the 
result is surprising, analysis of a simplified special case of the scenario shows that the 
expected number of messages flowing through the battalions’ headquarters is 
significantly more than the expected number flowing through a relay station. This 
analysis suggests that the bandwidth of the battalion headquarters is the true limiting 
parameter in a JTRS network. 
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I. 



INTRODUCTION 



As we enter the 21 st Century, the pace of technological change is accelerating at 
an exceptionally rapid rate. From on-line shopping and stock trading, to improved 
missile guidance systems, to the ubiquitous cellular phone and pager, the results and 
possibilities of new applications of technology are all around us. The ongoing 
development of technology offers opportunities to both the United States and potential 
adversaries throughout the world. 

The Marine Corps has applied great effort and thought into preparing to fight and 
win the future battles of the nation. Marine Corps Doctrinal Publication 1 (MCDP 1), 
Warfighting [Ref. 1] explains that, although the nature of war - a struggle between two 
independent and hostile wills - will not change, the methods used to achieve victory will. 
Therefore, a critical part of our preparation is considering the likely effects of technology 
on the conduct of war. 

The acquisition of the MV-22 Osprey tilt-rotor aircraft and the Advanced 

Amphibious Assault Vehicle (A AAV) will give the Marine operating forces of the future 

a huge increase in range, speed and flexibility in the execution of amphibious operations. 

Extensive thought on the efficient use of this increased capability has led to two Marine 

Corps Concept Papers. The Operational Maneuver from the Sea (OMFTS) Concept 

Paper [Ref. 2] describes the tenets and principles that will drive maritime power 

projection in the future. The Ship-To-Objective Maneuver (STOM) Concept Paper [Ref. 

$ 

3] describes, at the tactical level of war, how the concept of OMFTS will be implemented 
by the Marine Corps of the future. The STOM Concept Paper addresses the effects of 
technology as follows. 

Emerging technologies represented by the Advanced Amphibious 
Assault Vehicle (AAAV), MV-22 aircraft, global positioning system 
(GPS), and developing command and control systems will radically alter 
the nature of amphibious operations. Landing force units will possess 
their own mobility systems - and have the ability to independently 
navigate across the ocean surface to penetrate the enemy’s shoreline at 
points of their choosing... This combination of maneuver warfare 
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philosophy and emerging technologies will provide the naval force with 
enhanced combat effectiveness. [Ref. 3] 

The capabilities of current systems and procedures to support operations will be 
surpassed by the demands of executing OMFTS and STOM. The shortcomings of 
existing systems is not surprising because current systems and procedures were designed 
to support Marines as they fight today, not as we expect them to fight in the future. For 
example, current logistic systems in the Marine Corps cannot support a force engaged in 
combat at the extended distances envisioned by OMFTS. Equally important, current C4I 
systems do not have the ability to maintain the required connectivity with the assault 
force. Once the rapidly moving force starts its movement to the objective, it will quickly 
outstrip the range of existing communication systems. 

In current-day operations a Marine force conducting an amphibious operation 
must first establish itself ashore, build a logistic support area, establish terrestrial satellite 
communication stations, and then move to the objective. The OMFTS concept does not 
allow an operational pause at the beachhead, and so cannot initially rely on satellite 
communication for its long-haul, high bandwidth communication backbone. Only after 
the objective has been secured will the landing force have the security and time to set up 
satellite communications equipment. Until that time, C4I requirements will be met by 
organic, mobile C4I assets and retransmission or relay platforms. 

The Marine Corps Combat Development Process is designed to ensure that the 
requirements of the operating forces are met. In support of OMFTS, the Requirements 
Division of the Marine Corps Combat Development Command (MCCDC) has developed 
a Long-Term C4I Architecture. There are many uses of emerging technology in this 
proposed architecture, but no technology is more critical than the Joint Tactical Radio 
System (JTRS). This thesis looks at the question of J I RS relay suite bandwidth 
sufficiency through the use of a discrete-event simulation. 
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A. 



JOINT TACTICAL RADIO SYSTEM 



The JTRS is planned to be a multi-channel, multi-mode (voice, video, data), 
multi-band (2-2000MHz) family of radios to support the increased bandwidth and 
networking requirements of the warfighter of the future. The JTRS, as envisioned, will 
create a self-organizing, self-healing, network that will provide the high bandwidth C4I 
backbone for the Marine Air Ground Task Force (MAGTF) of the year 2015. In effect, 
the JTRS will be the backbone of a robust, high speed, digital Wide Area Network 
(WAN) that connects the Wireless Local Area Networks (WLANs) of subordinate units. 
Each WLAN will have one or more JTRS radios which act as gateways to the MAGTF 
WAN. 

The Operational Requirements Document (ORD) [Ref. 4] for the JTRS has been 
published, and defines many requirements for the radio system. While the ORD does 
define data-rate requirements for specific band, mode, and radio configuration 
combinations, it does not specify what the throughput capabilities of the communications 
relay suite should be. This is a critical question which needs to be answered in order to 
ensure that the C4I needs of the Marine Corps are met in STOM. 

The JTRS is in Phase 1 of the acquisition process, known as Program Definition 
and Risk Reduction, in which the desired operational capabilities of the system are 
described. As shown in the book Modeling Complex Computer and Communication 
Systems [Ref. 5], the cost to correct design errors and incorporate design changes goes up 

4 

by orders of magnitude as the project advances toward completion. These costs increases 
are indicated by the graph in Figure 1 . 

It can be seen, therefore, that it is vitally important to specify the true 
requirements of the JTRS as accurately as possible and as early in the development 
process as possible. Early and correct specification will provide the Marine Corps with 
equipment that meets its needs, and will avoid the large costs resulting from the late 
addition to required capabilities. 
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Figure 1. Relative cost of errors as related to phase of development. After [Ref 5] 
B. PURPOSE 

The purpose of this thesis is to analyze the bandwidth required for the JTRS relay 
suite to support United States Marine Corps forces ashore during amphibious operations 
in the year 2015. The nature of the technologies that will be incorporated into the 
MAGTF C4I Architecture is largely unknown at this time. Also unknown is the true 
current bandwidth requirements of Marine forces using today’s equipment and doctrine. 

This thesis develops a simulation to estimate the performance of the JTRS, given 
a combat scenario and a set of parameters describing the JTRS performance. This tool 
will allow the Marine Corps to identify, early in the combat development process, the 
likely bandwidth requirements that the JTRS must meet. In particular, the question of 
how much JTRS bandwidth is required to support STOM operations is examined. 

In the absence of a working JTRS network, a model of the JTRS portion of the 
future MAGTF C4I Architecture must be built. This model must be complex enough to 
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model the expected behavior of the JTRS and flexible enough to adapt in the event of 
changes to the operating characteristics of the JTRS. 

Once an appropriate model is developed, measures of effectiveness (MOEs) must 
be defined. The choice of MOEs to evaluate a system that does not exist, and which is 
designed to support doctrine that has never been exercised, is problematic at best. 
Fortunately, the JTRS is designed to fulfill a function for which there is a current analog 
in digital networks. The JTRS can thus be effectively evaluated using the same MOEs 
that are appropriate for current communications systems and computer networks. 
Although the methods, capabilities and technologies employed by the JTRS will be far 
different from the currently fielded systems, its purpose remains the same. 

The characteristic of the JTRS network selected for evaluation is the timely 
delivery of messages. This characteristic is measured by a weighted penalty function 
based on the number of messages that arrive late to their destination and the priority of 
those messages. The penalty function, then, is the MOE for the JTRS network. In this 
situation a lower MOE score is better, as it reflects fewer late message deliveries. The 
penalty function is more fully described in Chapter IV. 

A secondary measure of effectiveness for the JTRS is the number of relay sites 
required to support the landing force. The minimum number of relay sites to support an 
operation is heavily dependent on the scenario examined. In the simplest case of one 
headquarters and one maneuver element, the number of relay sites required is simply the 
number required to span the maximum distance separation between the headquarters and 

t 

its subordinate unit. In more complicated scenarios, those with multiple maneuver 
elements, the number of relay sites will go up, depending on the scenario examined. 
However, regardless of the topology of the network, this MOE is only a function of the 
range of the communication systems being used. Of interest however is the behavior of 
the network when additional relay sites are placed in parallel along the communications 
path. The effects of additional parallel relay sites can be examined using the Penalty 
Function. 
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c. 



METHODOLOGY 



This thesis will model the MAGTF C4I system using a discrete-event simulation 
and will employ the software package Simkit to implement the model. Analysis of the 
system simulation will be conducted using the statistics gathering features of Simkit. 
JTRS system parameters and scenario parameters will be varied to gain insight into the 
critical threshold requirements of the JTRS. 

D. THESIS ORGANIZATION 

The remainder of this thesis is organized as follows. Chapter II describes the 
background of the doctrinal and technical changes leading to this thesis. Chapter III 
describes the discrete-event simulation approach in general and Simkit in particular. 
Chapter IV describes the model developed for this thesis, it’s MOEs, and the scenario 
used to demonstrate the model. Chapter V contains the scenario results. Chapter VI 
contains conclusions and a recommendation and identifies areas for further research and 
improvement of the model. 
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II. BACKGROUND 



An appreciation of the doctrine supporting and directing Marine Corps forces in 
the year 2015 aids in understanding the nature of problem addressed in this thesis. Also 
important is an understanding of the likely employment of the JTRS in support of this 
doctrine as envisioned in the Marine Corps Long-Term C4I Architecture. 

There are unique challenges in modeling a communication system that has not yet 
been completely specified. This modeling effort is made doubly hard by the fact that the 
Marine Corps cannot even quantify current bandwidth requirements, due to a paucity of 
communications traffic data. Therefore, it is critical to understand the fundamental 
concepts of OMFTS and STOM, which are discussed next. Following that, the JTRS and 
the Marine Corps Long-Term C4I Architecture are addressed. The chapter concludes 
with a discussion of the lack of communications data, and the steps being taken to 
mitigate the problem. 

A. OPERATIONAL MANEUVER FROM THE SEA 

The information in this section is drawn entirely from the Marine Corps Concept 
Paper, Operational Maneuver From The Sea [Ref. 2], Although almost four years old, 
the OMFTS Concept Paper remains the key document used to describe how the Marine 
Corps will apply maneuver warfare to amphibious operations and take advantage of 
technological changes occurring now and in the future. 

The OMFTS Concept Paper is subtitled “A Concept for the Projection of Naval 
Power Ashore” and it makes a strong case for America’s need for a “...credible, 
forwardly deployable power projection capability.” [Ref. 2] This forwardly deployable 
force must have a “...forcible entry capability that is independent of forward staging 
bases, friendly borders, overflight rights, and other politically dependent support.” These 
needs point to U.S. naval forces (U.S. Navy and U.S. Marine Corps) with the strength to 
deal with any hostile action, be that action a natural disaster or enemy military activity, 
and the flexibility to do so at any time in any location. 
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The OMFTS Concept Paper describes the nature of the threats the Marine Corps 
expects to meet in the 21 s * Century, the response to those threats and the path which must 
followed to be able to have the proper response to future threats. The threats of the future 
cannot be known, but the trends of today can be projected forward to give hints about the 
enemies the United States and her Marine Corps will face. The OMFTS Concept Paper 
predicts three general threats to American security. 

The first of these threats is the rise in non-state fighters, those fighting for their 
religion, tribe, or ethnic group, but not associated with a particular nation state. While 
the world has had such fighters throughout history, the OMFTS Concept Paper predicts 
an increase in their numbers and activities in the evolving political scene. 

The second general area of threat is the developing regional powers. These 
powers are defined as nations with strong militaries that can dominate their neighboring 
states politically, militarily, or economically. OMFTS makes the point that not all of 
these regional powers will be threats to the security of the United States. Some of these 
regional powers will be hostile and some will be friendly, but all will have the ability to 
threaten the security of the United States. 

These two threats can be seen as a result of the end of the cold war and the fall of 
the Soviet Union. The collapse of the Soviet Union left the United States as the only 
superpower in the world. The third threat, and the most unknown, is the next 
superpower. History shows that a single dominant power remains dominant only for a 
limited time; eventually some new power arises to threaten the dominance. Accepting 
that America will have a rival superpower some time in the future does not tell us 
anything about that superpower. Such a superpower could be a current state, a new state 
we are unfamiliar with, or an alliance of states. The important assumption is that there 
will eventually be a superpower threat to American interests and the Marine Corps must 
be ready to meet that threat. 

In order to meet these threats, OMFTS has six defining characteristics. These are 
that Operational Maneuver From The Sea: 

1 . Focuses on an operational objective. 

2. Uses the sea as maneuver space. 
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3. Generates overwhelming tempo and momentum. 

4. Pits strength against weakness 

5. Emphasizes intelligence, deceptions, and flexibility. 

6. Integrates all organic, joint, and combined assets. [Ref.2] 

Figure 2, drawn from an OMFTS brief given by MCCDC [Ref. 6], depicts a 
notional example of OMFTS. Notice that this example focuses on an operational 
objective and uses the sea as maneuver space. Also note the huge distances to be crossed 
and communicated over. 

The concepts dealt with in OMFTS define the way ahead for the Marine Corps. 
In defining required capabilities, the OMFTS Concept Paper has this to say about 
Command and Control: 

The command and control system best suited to OMFTS will be very 
different from those developed to deal with previous approaches to amphibious 
warfare. Techniques previously employed to compensate for the inability of fire 
support units to see the battlefield will give way to techniques that exploit the fact 
that combatant units will be better informed than ever before. Communications 
systems designed to provide a few headquarters with an overall view of the 
situation will have to be replaced by those that provide units with control over the 
information they need. [Ref. 2] 

The STOM Concept Paper calls the OMFTS Concept Paper the “capstone Marine 
Corps Concept Paper.” [Ref. 3] As the capstone, the OMFTS Concept Paper serves as 
the master plan for how the Marine Corps approaches the challenges of the future. By 
necessity the OMFTS Concept Paper is broad and somewhat vague, dealing with topics 
as seemingly unconnected as the nature of the threat in the 21 st century, training and 
education, and command and control. The job of filling in the details is left to other 
Marine Corps Concept Papers. 
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Figure 2. An illustration of OMFTS. From Ref. [6). 



B. SHIP-TO-OBJECTIVE MANEUVER 

The background section of the STOM Concept Paper itself provides the best 
possible description of its purpose. 

Emerging technologies represented by the Advanced Amphibious 
Assault Vehicle, MV-22 aircraft, global positioning system (GPS), and 
developing command and control systems will radically alter the nature of 
amphibious operations. Landing forces will have their own mobility 
systems - and have the ability to independently navigate across the ocean 
surface to penetrate the enemy’s shoreline at points of their 
choosing. . . .These new capabilities will enable tactical commanders to 
make decisions as the situation develops to exploit enemy weaknesses and 
maintain the momentum of the attack from the ship to the objective. .. .This 
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paper, Ship-To-Objective Maneuver, describes this new tactical concept 

for conducting amphibious forcible entry. [Ref. 3] 

STOM seeks to apply the six key elements of OMFTS to the tactical execution of 
amphibious operations. STOM has distilled its own purpose as follows. 

1. Control tempo/overwhelm adversary. 

2. Combined arms maneuver from over the horizon (OTH). 

3. Dilute the enemy by enlarging battlespace. 

4. Control vital area by fighting outside it. 

5. Maneuver to cause and exploitable reaction. [Ref. 3] 

STOM is best described graphically. The remainder of this section will use 
various figures, along with discussion of STOM terms and concepts drawn from the 
STOM Concept Paper. 

Figure 3, drawn from the MCCDC Concepts Division’s Marine Corps 
Warfighting Concepts for the 21 st Century Brief [Ref. 7] shows the difference between 
today’s reality and tomorrows ideal. The Amphibious Task Force (ATF) consisting of at 
least U.S. Navy and U.S. Marine forces, and also possibly joint and multinational forces, 
launches an operation against a threat located at the objective (OBJ). Today, all Marine 
forces converge and establish a Force Beach Head Line (FBHL) in order to allow 
supplies and follow-on forces to be brought into the Beach Support Area (BSA). Only 
after this buildup and consolidation can the force move forward to seize the objective. 
This buildup will be avoided in the future. Under concept of STOM, maneuver forces 
will move directly to their objectives, following the path of least resistance, in order to 
maintain their combat power for the decisive action at the objective 

Figure 4 shows the mobility assets that will make STOM possible. The entire 
concept of STOM relies on these three vehicles, the AAAV, the MV-22 , and the Landing 
Craft Air Cushioned (LCAC), collectively referred to throughout the Marine Corps as 
“the triad.” These vehicles will increase the striking range of the MAGTF from where it 
is today to the distances shown in this figure. Note that the objective could be an 
additional 100-200 Nautical Miles (NM) from the shore. 
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Figure 3. Amphibious operations today vs. tomorrow. From [Ref. 7). 
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Figure 4. Depiction of a STOM operation. From [Ref. 6]. 
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The STOM Concept Paper sets forth the lexicon for future amphibious operations 
and attempts to add valid tactics to the Marine Corps leader’s set of skills. The ideas of 
STOM are supported by the triad of AAAV, MV-22, and LCAC. In order for these 
concepts to work, the command and control systems of the future must evolve to support 
STOM. The concept paper recognizes this and says the following. 

Command and control provide the mechanism by which a 
commander recognizes what needs to be done and communicates those 
actions required to ensure mission accomplishment... .Command and 
control systems must provide landing force commanders at all echelons a 
common operational picture and the connectivity to monitor execution and 
to influence events when necessary. 

[Ref. 3] 

The STOM Concept Paper indicates that there is an understanding among the 
Marine Corps leadership that the mobility triad alone is not enough to enable the Marine 
Corps to execute OMFTS and STOM. It is clear that that today’s C4I system must 
evolve into a more flexible and capable system to support the types of operations we plan 
to conduct. 

C. JOINT TACTICAL RADIO SYSTEM 

4 

The majority of the information contained in this section comes from the JTRS 
JPO website [Ref. 8], Because this is an active acquisition program, JTRS may be forced 
to change to adapt to developing technology or because of the limitations of technology. 
Despite this uncertainty, the basic facts presented here have remained unchanged since 
the Mission Needs Statement (MNS) [Ref. 9] for JTRS was written in 1997. 

JTRS will be an open architecture, software programmable system. This will 
allow future upgrades as the state of the art advances. The fact that it is software 
programmable will speed the upgrade process when it becomes necessary. This is a step 
beyond the traditional hardware-based digital radio of the current force. [Ref. 9] 
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JTRS will provide both line-of-sight and beyond-line-of-sight capabilities and 
will operate from 2-2000 MHz. JTRS will transmit voice, video and data. The 
waveforms required to meet this requirement have not been chosen, but this wide range 
of capabilities will put JTRS far ahead of any existing radio system. 

JTRS will be a family of radios. This family will provide communications for 
ground units, ships, and aircraft. The different domains will require different radios to 
perform their missions, but by relying on the common open architecture, all members of 
the family will be able to share waveform software and will remain interoperable. [Ref. 
8 ] 

By providing voice, video, and data transmission from 2-2000 MHz across the 
full spectrum of users on an upgradeable platform, JTRS can claim to be the “DoD radio 
of the future.” [Ref. 8] 



D. USMC C4I LONG-TERM ARCHITECTURE IN SUPPORT OF STOM 

The USMC C4I Long-Term Architecture is the umbrella term for the efforts that 
have gone into describing the architecture that will support Marine forces conducting 
OMFTS and STOM. It is in fact not the next generation architecture, but rather the 
architecture-after-next. 

The paper, “Overview of the Proposed 2010 Command, Control, Communication, 
Computers, Intelligence and Reconnaissance (C4ISR) Architecture for the Marine Corps” 
[Ref. 10], produced by the C4ISR Architecture Branch of the Requirements Division of 
MCCDC, provides the most accessible description of the probable attributes of the 
architecture-after-next. The paper’s abstract in its entirety is as follows. 

This paper briefly outlines the draft Marine Corps communications 
architecture for the year 2010. This architecture is characterized by 
numerous low-power wireless local area networks tied together by a self- 
organizing backbone of Joint Tactical Radio Systems radios. [Ref. 10] 
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This architecture is seen in Figure 5. Note that JTRS wide area network (WAN) 
is made up of JTRS nodes linking the wireless local area networks (WLANs) of 
subordinate units. Figure 5 also depicts the use of relays to maintain the network. These 
relays may be on the ground or airborne. 




Figure 5. Notional MAGTF C4I architecture in 2010. From [Ref. 10). 



E. DATA USED IN THIS THESIS 

The Marine Corps has not accurately quantified the bandwidth it requires to 
conduct combat operations today, let alone in fifteen years. Extensive work has been 
done by Raytheon Systems Company in modeling the USMC Regiment and Below 
Architecture, specifically looking at the Near Term C4I Architecture of the Marine 
Corps. According to a MCCDC brief to the JTRS Joint Program Officer (JPO) [Ref. 11]: 
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1 Detailed C2 traffic load information does not exist. > 

2. Digitization and doctrine are still relatively new. 

3. No collection of detailed traffic during actual deployment of systems has 
occurred. 

4. Load Method used by Raytheon System is based on ‘Best Engineering 
Judgment. ’ 

The result of this Raytheon simulation study, the USMC Communications 
Architecture Study: Final Report [Ref. 12] details the attempts made by the analysts to 
determine communication loads for the simulation. The study used the Marine Corps 
Message Event Occurrence (MEO) database. The MEO lists Marine Corps Operating 
Facilities (OPFAC), which can be described as the command and control nodes of the 
force. For each OPFAC the MEO database contains a listing of the type of messages that 
particular OPFAC might send to any other OPFAC. 

The MEO database does not describe the frequency of any message type. In the 
case of the Raytheon study, the analysts used their best judgment to determine the 
estimated number of times a particular message might occur in a given time period of the 
simulation. Similarly, the voice load of the network was simulated by a message 
generator that produced messages which have an exponentially distribute length, with a 
mean length of eight seconds. The frequency of voice transmissions was determined by 
setting voice load as a percentage of available bandwidth, varying by the phase of the 
simulation. While these are all defendable and required assumptions of the model, they 
point to the lack of precision in the description of the Marine Corps’ bandwidth usage. 

It will be very difficult for the Marine Corps to take the steps to predict future 
bandwidth utilization until current utilization is identified. New C4I systems are planned 
to add capability to the MAGTF. Similarly, some current systems will be phased out of 
service as new equipment is fielded. In order to predict future bandwidth requirements it 
is necessary to first identify current requirements and second to adjust that requirement 
by the anticipated changes to bandwidth requirements caused by the addition and deletion 
of specific C4I systems. 
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The traffic load question is a large challenge, and on the surface it may appear 
that the desired result cannot be attained. Fortunately, the Marine Corps is committed to 
improving our understanding of bandwidth requirements for the force of the future, and is 
continuing to develop the tools and metrics to quantify those requirements. MCCDC is 
funding Raytheon to further develop the Regimental Landing Team Mid-Level Fidelity 
Simulation Scenario. The results of this simulation, along with expected updates as 
architecture changes over the course of time, will provide a solid measure of the 
bandwidth requirements of USMC forces in a broad range of operations. 

This thesis will analyze the relay problem by developing a discrete-event 
simulation model that incorporates the key distance, bandwidth, and C4I load issues 
involved in STOM. The approach taken in the absence of empirical traffic size and 
frequency data is to provide notional message data for this thesis. Message size and 
inter-arrival times are treated as random variables and are assigned distributions. As the 
Marine Corps continues to explore the area of traffic analysis, data will become available. 
Those data, based on the Regimental Landing Team Mid-Level Fidelity Simulation 
Scenario, will further improve the validity of the model output. 
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III. DISCRETE-EVENT SIMULATION AND SIMKIT 



This chapter opens with a discussion of the reasons for selecting a discrete-event 
simulation as the method to be used to analyze the JTRS radio network in support of 
Marine Forces of the future. The chapter continues with an overview of discrete-event 
simulations, in order to aid in the reader’s understanding of Chapter IV’s description of 
the model. The chapter concludes with an introduction to Simkit, the program used to 
formulate the simulation. 

A. DISCRETE-EVENT SIMULATION 

Figure 6, drawn from Simulation Modeling & Analysis [Ref. 13], broadly depicts 
the methods that can be used to study a system. Each descending tier, reading from left 
to right, adds to the degree of abstraction. In the case of the JTRS, the lack of an existing 
system precludes experimentation with the actual system. The mathematical and 
analytical training of the operations researcher lead to a greater preference for, and ability 
with, building a mathematical model rather than constructing a physical model. Finally, a 
complex stochastic system, such as a military communication network, does not lend 
itself to analytical solution, thus leaving simulation as the preferred method to study the 
problem. This thesis will therefore use the discrete-event approach to simulation. 

Simulation Modeling & Analysis [Ref. 13] describes the discrete-event simulation 
method as follows. “Discrete-event simulation concerns the modeling of a system as it 
evolves over time by a representation in which the state variables change instantaneously 
at separate points in time.” [Ref. 13] The status of the system is tracked over the course 
of the simulation by the state variables of the system, an event list, and use of a 
simulation clock. It is possible to advance through the simulation either by time-step of 
by event-step. This thesis will use the event-step method of discrete-event simulation. 

State variables are those elements of the model of the system that change over 
time and describe the functioning, performance or abilities of the system. The values of 
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the state variables at any given time completely describe the system being simulated. 
That is to say that each element of the set consisting of all possible combinations of 
values of the state variables describes a particular state of the system as a whole. From 
this it follows that the only way to change the system is to change one or more of the 
state variables, thus transitioning to a new element of the set of possible values and so 
describing a new state of the system. State variables make instantaneous changes at 
discrete points in time, remaining fixed between these instantaneous changes rather than 
changing continuously. 




Figure 6. Ways to study a system. After [Ref. 13] 



The event list is simply a time-sequenced list of all future events scheduled for the 
system being simulated. Each of these events on the event list may schedule other future 
events or may change the state variables of the system, or both. 

The simulation clock controls the execution of the events stored on the event list. 
The clock moves in discrete blocks of time from the first event on the event list to the 
next. The simulation performs no work between events scheduled on the event list, 
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instead the clock “jumps” from the current rime to the time of the next event. When the 
simulation clock jumps to the next time for which an event is scheduled the events 
scheduled occur, have their effect on the system, and are then removed from the event 
list. The simulation clock then moves to the next time for which events are scheduled. 

The first step in simulating a system with the discrete-event approach is to define 
the state variables needed to describe the system to be simulated. Once the state variables 
have been defined, the next step is to determine all of the events that cause the state 
variables to change. This process requires careful analysis of the system at its most basic 
level. As a simple example, imagine simulating a queue of people. The single state 
variable that describes a queue is the number of people in the queue. There are only two 
events that can change the state variable: another person joins the queue, or a member of 
the queue leaves. At the most basic level then, a queue can be described by a single non- 
negative number which can be change by only two events. 

One very useful technique to support this decomposition and to aid in the 
description of discrete-event simulations is the use of an Event Graph. Event Graphs 
were introduced by Schruben in Simulation Modeling with Event Graphs [Ref. 14] and 
further discussed by Buss in Introduction to Event Graphs [Ref. 15], An Event Graph is 
a directed graph consisting of nodes and edges. The nodes of the Event Graph indicate 
the events of the discrete-event simulation and the edges are used to schedule future 
events. The edges of the Event Graph may include a scheduled time delay and can also 
have a Boolean condition controlling the scheduling of the future event. 

Figure 7 captures the essence of the event graph. When event A occurs, event B 
is scheduled with a time delay of toeiay from the current time, if the Boolean condition i is 
true. In the case where the Boolean condition is false the event is not scheduled. 
Described in the context of the event list, when event A occurs at time t A and i is true, 
event B is added to the event list at time ts = t A + today. The state variables of the system 
change only at the nodes of the graph, which represent the events that are capable of 
changing the state variables. These changes to state variables can be listed below the 
node in simple cases. More complex models may have too many state changes to 
explicitly list each and every one below its associated node. 
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Figure 7. The basic Event Graph construct. From [Ref.14]. 

Event Graphs will be used in this thesis to describe the simulation model. Two 
additional features of the Event Graph are used in this thesis: these are canceling edges 
and the passing of parameters along edges. Canceling edges are depicted by dashed lines, 
and indicate that the occurrence of event A causes the removal of the next scheduled 
occurrence of event B from the event list. Passing parameters allows information about 
the current state to be passed to future events. An event that expects and requires a 
parameter has the type of parameter (i.e. int, double. Mover) in parentheses below the 
event name. Any scheduling edge involving a passed parameter has the name of the 
parameter inside a box in the edge. 

B. SIMKIT 

Simkit is a simulation tool that utilizes the Java programming language to build 
discrete-event simulations. Simkit has three major underlying themes that will be 
described below: loosely coupled components, the listener pattern, and control of 
information. 

Simkit simulations are closely related to the Event Graph. Recall that the nodes 
of an Event Graph correspond to the events that describe the system. The Java methods 
written in a Simkit simulation have roughly the same name as the events on the Event 
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Graph. The word “do” is simply added to the beginning of the event name to form the 
method name. For example, the Simkit code written to implement Figure 7 would have 
two methods, do A and doB. 

The scheduling arcs of the Event Graph are incorporated into Simkit by use of a 
“waitDelay” statement inside a “do” method. The “waitDelay” statement includes the 
name of the event to be scheduled, the time to delay before executing the event, and any 
parameters to be passed to the future event. An example of a completed Java method for 
the Event Graph in Figure 7 is as follows. 

public void doA() { 

if (i) { 

waitDelay (B, tDelay) ; 

} 

} 

Similarly, the canceling edges of the Event Diagram are incorporated into Simkit 
by use of an “interrupt” statement inside a “do” method. The “interrupt” statement 
includes the name of the event to be canceled and any parameters to be passed to that 
event. 

Simkit has a small suite of components ready-made for discrete-event simulation. 
Examples of these components include a Basic Mover and a Cookie Cutter Sensor. The 
Basic Mover moves from one point to another using instantaneous constant velocity. 
When a Basic Mover reaches the point it was moving to, it stops and does nothing else 
unless some external entity provides a new destination. The Cookie Cutter Sensor is a 
sensor with radial range of R. The sensor detects targets closer than R units away with 
probability 1 and detects all other targets with probability 0. 

Simkit is based on the concept of loosely coupled components. That is to say that 
each modular component is responsible for executing its own simple task and typically 
requires no knowledge of the source of its inputs or what is done with its outputs. For 
example, the Basic Mover moves to whatever coordinates it is told to move to with no 
concept of the reason why. 
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The key to control of the entities in Simkit is the event listenej paradigm. The 
listener construct is to register certain entities as listeners of other entities. After this 
registration, the listener entity will “hear” whenever the listened-to entity executes a 
method. In those cases where the listener has a method of the same name as that just 
executed by the listened-to entity, the listener’s method will also be executed. For 
example, an entity named a Mover Manager may be registered to listen to a particular 
Basic Mover. When the Basic Mover executes its doEndMove method, the Mover 
Manager will “hear” the doEndMove method of the Basic Mover and will execute its 
own doEndMove method. 

Another key basis for Simkit is the control of information. The thesis Sensors in 
Object Oriented Discrete Event Simulation [Ref. 1 6] contains a discussion on the reasons 
to control access to information in a simulation. These reasons include memory savings, 
greater fidelity to reality, and robustness [Ref 14]. Simkit approaches this need to control 
information by use of Referees. The purpose of the Referee is to arbitrate the interactions 
among entities in the simulation. Multiple Referees may be required in keeping with the 
loosely coupled nature of Simkit, with each Referee being responsible for only one type 
of interaction. An example of the need for a Referee is the interaction between a Cookie 
Cutter Sensor and a Basic Mover. The Cookie Cutter Sensor needs only to know when a 
target has been detected; indeed, the sensor should specifically not know in the case that a 
target was close to entering detection range R but then stopped. Likewise, the Basic 
Mover has no reason to know that it has been detected by the sensor, nor to know that it 
is about to enter the sensor’s detection range. This interaction is controlled by a Referee 
that keeps track of the location of the Basic Mover and the Cookie Cutter Sensor. When 
the Basic Mover enters the detection range of the Cookie Cutter Sensor, the Referee 
notifies the Cookie Cutter Sensor of the location of the Basic Mover and tells the Basic 
Mover nothing about the existence of the sensor, thus maintaining the logical flow of 
information in the simulation. 

Chapter IV will describe the use of Simkit and event graphs to model the JTRS 
network. It will also discuss the scenario developed to exercise the model. 
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IV. DESCRIPTION OF MODEL AND SCENARIO 



This chapter gives a brief description of the model constructed to simulate the 
Marine Corps C4I system in 2015. The chapter concludes with an explanation of the 
OMFTS scenario used to demonstrate the model and for analysis of bandwidth 
requirements. The aim of this chapter is to provide an understanding of the functioning 
of the model through descriptions the use of Event Graphs. 

A. MODEL DESCRIPTION 

The system to be modeled is similar to a civilian computer network, with the 
exception that the elements in this network move across a battlefield. Thus, there are two 
major functions captured by the model: the communication function and the movement 
function. In keeping with the loosely coupled philosophy, these functions are separated 
from each other to the greatest extent possible. However, since the functions of the 
network are strongly dependent on the actions of the movement components, they are 
more tightly coupled than most Simkit simulations. 

The simulation moves entities across the battlefield generating messages of 
differing priority, depending on the situation. A generated message must flow through 
the network to get to its intended recipient. Each entity has a limited amount of 
bandwidth available to transmit and receive messages and this available bandwidth is 
reduced as a function of the size of any messages being processed. 

When a message is transmitted to an entity that lacks the available bandwidth to 
receive that message (i.e. the entity is currently handling several earlier messages), that 
message will be “dropped”. That is to say that the receiving entity will not receive the 
message and will not know that it missed a message. However, the entities do have the 
ability to store both generated messages and previously received messages for later 
transmission. Since messages are stored only when an entity is fully occupied sending or 
transmitting, the number of messages waiting to be sent is a measure of the load on the 
network. Smaller queues indicate a smoothly functioning network, with bandwidth 
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capacity in reserve, and longer queues indicate a network struggling to keep up with the 
flow of message traffic. 

Each entity keeps a list, known as the network, of all entities that should be part of 
the communications network. Each entity also keeps a separate list, known as the 
commList, of all other entities that it is currently in direct communication with. The sum 
of the information contained in the commLists of all entities describes the topology of the 
communications network at any given time. The network list is all those entities that 
should be able to get communications to each other across the network, while the 
commList is a subset of the network list of only those in direct, “one-hop” 
communication at a given time. The network list does not change throughout the 
simulation, while every commList is dynamic and does change as the scenario unfolds. 

If a generated message is intended for an entity on the generator’s commList, the 
message is sent directly to that entity. If the recipient is not on the sending entities’ 
commList, an element on the commList is selected and the message is sent to that entity 
in the hopes that this new holder of the message will have the message’s recipient on its 
commList. This process is repeated until the message reaches the recipient. The strength 
of this system over current tactical communications is that one unit need not have direct 
communication with another in order to pass intelligence or request support; rather a unit 
only needs to know that the target of its message is a member of the network. 

Receipts are generated when a message reaches its recipient. Each receipt then 
transits the network back to the originator of the message for which the receipt was 
generated. The receipt flows through the network using the exact same procedure as the 
original message, but may follow a different path to reach its destination. To avoid 
unnecessary and unrealistic network saturation, the size of receipt messages is set to 0. 1% 
of the capacity of a JTRS. 

Each message transmitted has a predetermined delay time for retransmission. 

After that delay, the message will be retransmitted unless a receipt has previously arrived. 
This feature guards against the fact that a saturated network will drop some messages. 

The information passed in every message is considered important, so the model attempts 
to ensure that the information arrives where it is needed. 
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The network is made up of a series of objects of the type JTRS. Each JTRS 
represents the command and control hub for a particular military unit in the scenario. 

The JTRS object is a container for a collection of other objects. Among these are: 

1 . ArrivalProcesses 

2. QueueManager 

3. Receiver 

4. Transmitter 

The listener pattern allows each component to perform its own unique function 
while getting information it needs from other JTRS components. It is necessary to have 
an understanding of the functioning of each component before discussing the actual 
listener pattern implementation of this model. 

The ArrivalProcesses associated with each JTRS are responsible for simulating 
the occurrence of an event requiring generation of a message at the unit. The JTRS has 
an array of ArrivalProcesses, one for each message priority level that exists at that 
particular JTRS. For example, in the case where a JTRS is capable of generating 
message of priorities Routine, Immediate and Flash, that JTRS would have three separate 
ArrivalProcesses. 

The ArrivalProcesses in this simulation assume that message arrivals constitute a 
Poisson process, and thus have exponential inter-arrival times. The model has the ability 
to change the arrival rate of the Poisson processes, depending on the combat situation of 
the JTRS. However, if further data collection by the Marine Corps indicates that a 
Poisson process is not the best way to model the arrival of messages in the C4I system, 
this model is capable of switching to the better distribution simply by replacing the 
current arrival processes with new ones. This is a case of increased flexibility thanks to 
loosely coupled components: The JTRS does not care what method the ArrivalProcesses 
are using to generate arrivals, only that an ArrivalProcess says “doArrival.” Figure 8 is 
the Event Graph (See [Ref. 13] and [Ref. 14]) of the ArrivalProcess. 
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Figure 8. Event Graph for ArrivalProcess. 



The QueueManager is responsible for sorting and storing all messages waiting to 
be sent by the JTRS. Messages can be added to the outgoing queue for one of three 
reasons. The creation of a message by the JTRS causes that message to be queued. The 
second event causing a message to be queued is the arrival of a message destined for 
some other JTRS. The third way a message can be added to the queue is if a message has 
been erroneously sent to the Transmitter without sufficient bandwidth to actually transmit 
the message. Figure 9 is the Event Graph for the QueueManager. 

The QueueManager sorts messages first according to message priority and then 
by the time the message was generated, known as the timestamp. Messages of higher 
priority are placed in the queue ahead of all messages of lower priorities. In the case of 
messages with the same priority, the message with the earliest timestamp enters the queue 
in front of all those with later timestamps. 

Whenever the bandwidth available to the JTRS increases, or a message is added 
to the queue, the QueueManager checks the queue for messages to be sent. A message 
can be sent if its bandwidth requirement is less than the bandwidth available to the JTRS 
and the message does not have special instructions to be sent only at a later time. The 
QueueManager steps through the queue until either a message that can be sent or the end 
of the queue is reached. If the queue contains a message that can be sent, the 
QueueManager removes that message from the queue and sends it to be transmitted, 
which in turn causes the available bandwidth of the JTRS to be decreased. The 
QueueManager then checks the queue again, comparing message sizes to the current. 
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decreased bandwidth available. This process is continued until the queue is empty or the 
QueueManager reaches the end of the queue without finding a message to send. That is 
to say, until all messages in the queue have been sent to be transmitted, or until there are 
no messages in the queue that can be transmitted with the bandwidth remaining. 

The final function of the QueueManager is to remove specific messages from the 
queue when told to do so. The model’s usage of this function is to remove messages 



scheduled for retransmission at a later time if a receipt for that message arrives before the 
retransmission time. 




Figure 9. Event Graph for QueueManager. 

The Receiver class receives messages from transmitters within communication 
range of its JTRS. Upon arrival of a message, the Receiver notifies the JTRS of the size 
of the message. This causes the bandwidth available to the JTRS to be immediately 
decreased by the size of the message. The Receiver also causes the JTRS to schedule the 
return of the bandwidth committed to receiving the message after a time delay equal to 
the time spent receiving the message. Figure 10 is the Event Graph for the Receiver. 
Each received message is categorized by the Receiver as one of the following 

types: 
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1. For this JTRS and as a receipt for a previously sent message. 

2. For this JTRS and not as a receipt. 

3. Not for this JTRS. 

A message of type 1 causes the Receiver to notify the QueueManager to remove 
the message scheduled for retransmission from the queue. A message of type 2 causes 
the Receiver to generate a receipt and to send the receipt to the QueueManager for 
addition to the queue. A message of type 3 is sent immediately to the QueueManager. 

The Transmitter object gets messages from the QueueManager and broadcasts 
them to Receivers within communication range. Each message sent to the Transmitter is 
evaluated to ensure the JTRS has sufficient bandwidth to send the message. If the 
bandwidth available is greater than that needed to send the message, the Transmitter send 
the message to one of the Receivers within communication range. The Transmitter picks 
a Receiver to send to by first checking to see if any elements on the commList are the 
intended recipient of the message, in which case the Transmitter sends to that Receiver. 

If the message’s recipient is not on the commList, the Transmitter arbitrarily picks a 
Receiver on the commList and sends the message. The Transmitter takes exactly the 
same steps as the Receiver to help the JTRS keep track of current bandwidth available. 
Figure 1 1 is the Event Graph for the Transmitter. 

In addition to containing the above components, each JTRS also handles three 
specific functions. The first of these is to generate message objects when the 
ArrivalProcess has an arrival. The second function of the JTRS is to track its own 
bandwidth available. This is done by listening to the Receiver and Transmitter as they 
announce the size and duration of each message. The final function is to accept changes 
to the situation by changing the arrival rates of the ArrivalProcesses. This function 
allows the simulation of differing intensities of action and combat. The Event Graph for 
the JTRS is shown in Figure 12. 
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Figure 10. Event Graph for Receiver. 
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Figure 11. Event Graph of Transmitter. 
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Figure 13 shows the listener pattern used by the network. Information flows in 
the direction of the arrows, that is the object at the point of the arrow is the listener and 
listens to the object at the origin of the arrow. The plain bold arrows indicate how the 
components of a single JTRS interact. The bent arrow indicates a listener pattern set up 

4 

between JTRSs. Each Receiver is a listener to all Transmitters of the JTRSs on the 
Receiver’s JTRS’s commList. This enables the transmission of messages between the 
elements of the network. 
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Figure 13. Listener pattern for communication network. 

The movement of the JTRS sets around the battlefield is accomplished by 
associating each JTRS with a unique Mover object. The JTRS in effect “rides” on the 
Mover. The following are two additional objects contained in the JTRS: 

1. CommMover 

2. BasicSensor 

The BasicMover is a class provided in Simkit and moves only in a straight line 
from one point to another, with instantaneous and constant velocity. The BasicMover is 
provided a destination by another Simkit class, the PathMoverManager. Once the 
BasicMover arrives at its destination it announces doEndMove, which is heard by the 
PathMoverManager, who in turn passes the next point for the BasicMover to move to. 
The PathMoverManger is provided by the user a list of coordinates which describe the 
path of the BasicMover. Once the PathMoverManager stops sending new coordinates to 
the BasicMover, the mover stops. 

The network topology is descnbed by the sum of the information contained in all 
of the commLists maintained by the JTRSs in the simulation. The JTRS keeps track of 
its own commList by using an extension of another Simkit process. 
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Simkit comes equipped with the BasicSensor, which is a cookie cutter sensor, as 
discussed in Chapter III. The BasicSensor is built to locate Movers, of which 
BasicMover is a sub-class, and so can be detected. Simkit also includes a Referee class to 
keep track of interactions among entities, and a CookieCutterMediator to mediate the 
interactions identified by the Referee. 

The Referee and the CookieCutterMediator ensure that no undeserved 
information is passed to either the Mover or the BasicSensor, in keeping with the 
information protecting principle of Simkit. Specifically, any Mover detected by the 
BasicSensor is not passed directly to the BasicSensor, rather a new object called a contact 
is passed to the BasicSensor. This prevents the BasicSensor from having access to the 
methods and variables of the Mover, as could be the case if an actual reference to the 
Mover was passed instead of the contact. These contacts are recorded by the BasicSensor 
on a DetectionList. The Referee and CookieCutterMediator together keep the 
BasicSensor’s DetectionList up to date, adding contacts as they enter range and removing 
contacts from the list as they exit range. 

The nature of this problem is somewhat different in that the JTRSs are 
cooperative and, once in range, they will want to share their identities in order to update 
commLists and pass messages. Three actions are required to change the existing Simkit 
methods to support this simulation. First, the CookieCutterMediator is extended by a 
new CommLinkMediator class. This new class passes an actual reference to the Mover 
detected by the BasicSensor, rather than a contact. Secondly, the BasicMover is extended 
by a CommMover class. This CommMover class differs from a BasicMover in that the 
CommMover is built to carry a JTRS and knows that it is associated with a particular 
JTRS. The association of an entity to a BasicMover, on the other hand is one-way only; 
the riding entity knows it is associated with a BasicMover, but the BasicMover does not 
know about its rider. The final step to maintaining the commList is for the JTRS to ask its 
BasicSensor for the sensors DetectionList. Because of the CommLinkMediator, this is 
actually a list of all CommMovers within range of this JTRS. Because these are 
CommMovers, and are thus aware of carrying a JTRS, they can report a reference to the 
JTRS they are associated with. The JTRS simply gets the DetectionList from its 
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BasicSensor, polls each CommMover on the DetectionList to leam the identity of the 
CommMover’s JTRS, and adds that JTRS to the commList. The Referee and 
CommLinkMediator will keep the BasicSensor’s contactList current and accurate, which 
will in turn allow the JTRS to keep an accurate commList. 

B. SCENARIO DESCRIPTION 

The simulation developed for this thesis is flexible enough to be applied to a 
myriad of communication networking situations. A single representative STOM scenario 
will be detailed in this section and the results of that scenario examined in Chapter V. 

The scenario is constructed to include all of the communications challenges of STOM 
and to fully exercise the simulation. 

The year is 2015 and a U.S. naval amphibious force is located off the coast of a 
hostile country, prepared to conduct operations in support of national interests. The 
landing force is composed of elements of the 8 th Marine Regiment (8MAR) and 2 nd Tank 
Battalion (2TkBn). All forces are equipped with WLAN at the company level and with 
JTRS for communication above the company level. Each battalion will conduct the 
attack with three companies on the ground, plus a battalion headquarters. For clarity the 
units are referred to by their battalion headquarters’ names, although all units would 
actually be task organized, with elements attached and detached as the situation indicates. 

The commander’s estimate of the situation, aided by national and theater level 
intelligence, is that the enemy will likely lose the will to fight if his capital is seized. As 
a result of this estimate, an operations order has been prepared, assigning 8 th Marines the 
mission of seizing two objective areas. Objective A (OBJ A) is the capital itself and OBJ 
B is a military barracks that can be expected to attempt to reinforce the capital’s garrison 
force. 

The operations order calls for a supporting attack by 1 st Battalion, 8 th Marines 
(1/8) against OBJ B and the main attack by 2 nd Tank Battalion (2TkBn) and 2 nd Battalion, 
8 th Marines (2/8) to seize OBJ A. The supporting attack is scheduled for 0100 local time, 
and must take place before the main attack on OBJ A starts. It is expected to take 90 
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minutes of combat to secure OBJ B to the extent that the main attack can hit OBJ A 
without fear of enemy reinforcements, and an additional 60 minutes to complete the 
seizure of OBJ B. Given that OBJ B cannot reinforce OBJ A, it is expected to take 90 
minutes of combat to defeat the garrison force at OBJ A. 

Table 1 lists friendly forces for this operation. The Trans column indicates which 
member of the mobility triad will be used for the Ship-To-Objective movement. In the 
case of the tanks, LCAC transportation will be used to get to the shore and from then on 
the mobility of the tanks themselves will be used. Speed refers to the expected rate of 
unopposed advance for each unit. Speed listed in the form speedl/speed2 refer to the 
different speeds on water and on land, and can be read as waterspeed/landspeed. 



Unit 


Location 


Objective 


Trans 


Sneed (Kts) 


8 th Marine Regiment 


Shipping 


NA 


NA 


NA 


1 st Battalion, 8 th Marines 


Shipping 


B 


V-22 


210/2 


2 nd Battalion, 8 th Marines 


Shipping 


A 


AAAV 


20/25 


2 nd Tank Battalion 


Shipping 


A 


LCAC 


40/25 



Table 1. Friendly forces. 8th Marines Headquarters will remain aboard shipping. 



Figure 14 is a rough diagram of the scheme of maneuver. The assault will come 
from over the horizon, keeping the support elements and shipping safe from land based 
threats. The amphibious force is currently approximately 50 nautical miles offshore. , 
OBJ B, the military barracks is another 30 nautical miles inland, while OBJ A, the 
capital, is 125 nautical miles from the coast. 

The JTRSs in this scenario have their maximum range set to 35 nautical miles. 

The extended distance of 175 nautical miles will require pre-planned relay stations in 
order to maintain communications. The 8 th Marines Regimental Communications Officer 
has planned for a series of relay stations between the two objectives and the command 
element aboard shipping. The relay equipment and personnel will accompany the assault 
forces with the main attack, and will start relaying when the force arrives at each relay 

station’s designated location. The relay stations in support of the attack on OBJ B will be 
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inserted prior to the attack, thus ensuring that they will be ready to relay when the assault 
occurs. The coordinates of the Objectives, Amphibious Force, and the Relay Sites are 
listed in Table 2. 




Figure 14. Ground Combat Element scheme of maneuver. 



Unit/Objective 


Location 


Amphibious Force & 8 th Marines 


(0.0 , 0.0) 


Relay 1 


(21.21 ,21.21 


Relay 2 


(42.42 , 42.42) 


Relay 3 


(63.63 , 63.63) 


Relay 4 


(84.84 , 84.84) 


Relay 5 


(106.05 , 106.05) 


Objective A 


(123.74,123.74) 


Relay 6 


(23.1 , 13.33) 


Relay 7 


(46.2 , 26.66) 


Objective B 


(69.28 , 40.0) 



Table 2. Location of Relay Sites and Objectives. 
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The simulation has a total of 13 entities on the battlefield, four per battalion and 
the Regimental Headquarters. There are three levels of communications intensity for 
each entity in this scenario. Each level of intensity is described by both the frequency of 
messages, and the urgency or priority of the messages generated. Frequency is a measure 
of the arrival rate of messages in the ArrivalProcess. The urgency of messages is a 
description of the distribution of messages between the priority levels modeled 

The first communication intensity level, low intensity, is low frequency, low to 
middle priority. This level is the default at the start of the simulation and is the level of 
intensity expected during an unopposed movement, where messages are infrequent and of 
a routine nature. The second level, middle intensity, corresponds to a tactical movement 
to contact, in which the unit is covering previously unseen terrain and is unsure of the 
location of the enemy. Messages are more frequent than the first level, but retain the 
same proportions of arrival. 

The last and highest communications intensity, high intensity, is high frequency 
and high priority. This is the level that reflects a unit in actual combat. Message arrival 
rates peak and the priority of these messages is very high. Very few low priority 
messages are even generated, which is an attempt by the simulation to model the real 
changes that occur on communication networks when engaged in combat. Table 3 details 
the interarrival times sent to the arrival processes. 

In this scenario each battalion is assumed to have the same communication 
intensity throughout its sub-units. It is possible to set each entity’s communication 
intensity individually. However, for the sake of simplicity in the scenario, each battaljon 
changes communication intensity as a whole. 



39 



Communications Intensity 


Message Priority 


Mean Interarrival 
"Time (Minutes) 




High 


60.0 


LOW 


Middle 


6.0 




Low 


3.0 




High 


12.0 


MID 


Middle 


1.2 




Low 


0.6 




High 


0.3 


HIGH 


Middle 


0.6 




Low 


6.0 



Table 3. Interarrival times of messages. Model varies times as intensity changes. 



All units start the simulation at the low intensity setting. First Battalion, 8 th 
Marines, the unit conducting the supporting attack on OBJ B, remains at low intensity 
until landing on OBJ B, at which point the unit changes to high intensity. The main 
attack changes to mid intensity once landfall is made and the movement to OBJ A begins. 
Upon reaching OBJ A, the main attack’s intensity changes to high intensity. The 
headquarters element’s intensity level is set to be the maximum intensity level of any 
subordinate unit. 

All units start collocated with the Regimental Headquarters. 2/8 in AAAVs 
moves first, followed by 2TkBn on LCACs, phased so that both forces arrive at the beach 
at the same time and location and can move toward OBJ A together. 1/8’s attack on OBJ 
B is scheduled for 0100 and the main attack is scheduled for 0300. This timing allows a 
30-minute delay beyond the 90 minutes predicted for 1/8 to accomplish its mission while 
seeking to maximize the confusion of the enemy by nearly simultaneous attacks. Table 2 
shows the scenario’s assault timeline. 
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Time 


Event 


1930 


2/8 starts movement to shore 


2045 


2TkBn starts movement to shore 


2200 


2/8 and 2TkBn ashore, starts movement to OBJ A 


0038 


1/8 starts movement to OBJ B 


0100 


Assault on OBJ B 


0230 


Expected conclusion of battle on OBJ B 


0300 


Assault on OBJ A 


0430 


Expected conclusion of battle on OBJ A 



Table 4. Assault timeline. 



The scenario will be simulated from the movement of the first unit to the expected 
conclusion of the battle on OBJ A. 

The MOE for the scenario is a weighted penalty function assigns a cost for each 
late message. The Penalty Function assigns a base cost of one to a late low priority 
message. A late middle priority message is three times as costly, and a late high priority 
message is five times as costly, as a late low priority message. The model also defines 
late differently for each priority of message, as indicated below: 

PENALTY P = 5*H + 3*M + 1*L 

Where H = Number of high priority messages not delivered within 1 minute. 

M = Number of middle priority messages not delivered within 3 minutes. 

L = Number of low priority messages not delivered within 10 minutes 

A special purpose Java class, PenaltyCalculator was constructed to manage the 

MOE. The count of late messages is tracked during the simulation scenario by 

calculating the time to delivery of each message that arrives at the Receiver of the JTRS 

that is the target of the message. If the current simulation time minus the timestamp of 

the message minus the transmission time of the message exceeds the delivery threshold, 

the PenaltyCalculator is notified and records the late delivery. The Penalty Function only 

considers those messages sent between 8 th Marines and the three battalion headquarters in 

41 




computing the count of late messages. Intra-battalion messages do not count against the 
systems performance. 

After the simulation is complete, the queue of each QueueManager is checked for 
undelivered late messages and the PenaltyCalculator updates the MOE. The final Penalty 
is reported at the end of the scenario. 

The effects of varying the bandwidth of the relay sites will be examined by 
observing corresponding changes in the Penalty Function. Due to the lack of good 
communications data, this bandwidth is described as a multiple of the bandwidth 
associated with a normal JTRS node. In other words, two relay sites might be described 
as having bandwidth of 1.0 and 1.5 respectively, which is to say that the first relay site 
has the same bandwidth as all non-relay JTRS nodes in the network, while the second has 
1 50% of the bandwidth of non-relay nodes. 

The scenario will also be modified to examine the effects of parallel relay sites. 
This will be modeled by adding a second relay site at each relay position listed in Table 
2. The results of the basic scenario, along with this modification are presented in Chapter 
V. 



42 



V. SCENARIO RESULTS 



The reason for developing this simulation was to examine the bandwidth 
requirements of the JTRS in support of a STOM scenario. It was believed that the relay 
sites in the scenario would be the weak links in the communication network. The actual 
results of the simulation do not support that belief. The surprising result was that the 
effectiveness of the network, as measured by the penalty function, was relatively 
insensitive to the bandwidth of the relay sites. This chapter will explore both the results 
of the scenario and will use a simplified expected value analysis to examine these 
counter-intuitive results. 

A. BASIC SCENARIO 

The model was extremely sensitive to the arrival rates of messages. The arrival 
rates used in the scenario were decided upon by testing the network when all units were 
co-located and so were assured of being able to reach the target of any message in one 
hop. The network held up under low and mid communications intensity levels, but 
queues built up when set to the high intensity level. This queuing was a desired feature 
of the model and is intended to portray the stress of combat on the network. 

No matter what arrival rates were presented to the model, it remained insensitive 

to relay bandwidth. The Penalty Function rises when more messages arrive in the system 

/ 

and falls when the arrival rate is lower, but within each arrival rate the Penalty Function 
remains insensitive to relay bandwidth changes. 

The value gained from the model is exactly that it did not behave as expected. 

This caused additional examination of the system being modeled and the model being 
used. Detailed, but of course less than exhaustive, exploration of the model’s behavior 
indicates that it is behaving as described in Chapter TV. 

In testing the effects of relay bandwidth on the penalty function, a total of 20 trials 
were run at each of several relay bandwidth level. Columns two and three of Table 5 
show the mean and standard deviation of the penalty function at the bandwidth level 
indicated in column one. Column four is a nonparametric approximate 90% confidence 
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interval for the median based on the binomial distribution, as described and tabled in 
Practical Nonparametric Statistics [Ref. 17], Figure 15 is a graphical depiction of the 
point estimators of the mean penalty function at each level of bandwidth. 

Special attention is drawn to the case in which relay bandwidth was set to 0.0. 
The Penalty Function in this case is calculated from the total number of messages 
generated when relay was required. During significant portions of the scenario the two 
battalion headquarters and 8 th Marines were within radio range of each other and so did 
not require relay. The results in Table 5 seem to indicate that the Penalty Function 
variations between the bandwidth levels is a result of noise in the simulation and not 
because of any response change as a result of relay bandwidth changes 



Relav bandwidth 


Mean Penalty 


S.D. of Penalty 


90% Cl for median of Penalty 




Function 


Function 


Function 


0.0 


878.6 


324.8 


(719 , 852) 


.25 


776.2 


156.3 


(689 , 784) 


.5 


805 


171.1 


(696 , 897) 


1 


849.9 


310.8 


(706 , 778) 


2 


936.1 


427.5 


(636,971) 


5 


766.7 


305.4 


(613 , 834) 



Table 5. Results of simulaton runs. 



A nonparametric median test was performed [Ref. 17] on the six bandwidth 
levels. The purpose of the median test is to determine if several samples came from 
populations having the same median [Ref. 17], which is the null hypothesis. If the null 
hypothesis is not rejected in this case, it would indicate that the Penalty Function 
variations observed in the simulation runs are a result of normal random fluctuations in 
the simulation, rather than a change in the underlying distribution. 

The procedure calls for pooling all data and determining the median of that group, 
which is referred to as the grand median. Each sample is then divided into two groups: 
those observations above the grand median and those at or below the grand median. The 
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number from each sample in either group (above median or not) are then tabled. See 
Table 6 for the results from the simulation output. 




0 1 2 3 4 5 6 

Relay JTRS bandwidth 



Figure 15. Penalty Function mean value vs. JTRS relay bandwidth 



Sample Bandwidth 


0.0 


0.25 


0.5 


1.0 


2.0 


5.0 


Totals 


>Median 


12 


11 


9 


12 


9 


7 


a=60 


<=Median 


8 


9 


11 


8 


11 


13 


b=60 


Totals 


20 


20 


20 


20 


20 


20 


N 



Table 6. Median Test cell counts. 



When a=b, as in this case, the test statistic T for the Median Test is computed as 
follows: 



r =1 



( o„ - o 2l ) 



n 



2 



Where: 

c is the column, or population from which a random sample was drawn. 
O x ; is the number of observations in row 1 or row 2 in column i. 
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nj is the size of the random sample drawn from the A population. 

In this case all n; = 20. 

Under the null hypothesis that the samples all come from populations with the 

same median, T is distributed is as follows: T ~ Xc-i 

The test statistic is 3.45. The p-value for a result of 3.45 from a Chi-squared 
distribution with 6-1=5 degrees of freedom is .6309. Therefore we can not reject the null 
hypothesis that the six samples came from distributions with the same mean. 

Both Table 5 and Figure 15 indicate that significant changes to the relay 
bandwidth do not cause corresponding significant changes to the penalty function. There 
are two possible explanations for this model behavior. Either the model is not correctly 
simulating the true nature of the system, or the real system may behave this way. It is 
likely that both of these possible explanations are at least somewhat true and in 
combination yield this surprising result. 

It is possible that the simplistic message routing scheme and description of 
bandwidth used in this model may be causing behavior that is not consistent with the real 
system. The system being simulated is so large and has so many actions and interactions 
that some level of abstraction is necessary in order to produce a simulation that can be 
run on a desktop computer. 

The results of the parallel relay system are actually worse than for single relays. 
This too may be caused by the way in which the model picks where to route messages; 
parallel relay sites allow more choices for routing and increase the probability that a 
message will go the “wrong” direction. Given the model’s demonstrated insensitivity to 
any changes in relay bandwidth, it should not be surprising that adding bandwidth to the 
relay positions did not help the Penalty Function at all. 

Regardless of this result, a parallel relay system is more robust than a single relay 
system in real-world operations. Equipment failures and enemy actions can be expected 
to occasionally cause the loss of a relay site to the network. In the single relay system, 
this has the potential to cause elements of the network to be isolated from the rest of the 
network if the failure occurs at a key relay node. The primary factor favoring the single 
relay system is cost. If system A has half the bandwidth capacity of system B, but costs 
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75% of the cost of B, then A will never be favored from a financial standpoint; simple 
algebra tells us that each “unit” of bandwidth is 50% more expensive for system A than 
for system B. Because of this financial unattractiveness, system A is unlikely to be 
selected as the system of choice, despite the tactical flexibility and robustness it brings. 

It is remains possible that the real network itself may be fairly insensitive to relay 
bandwidth, especially at the high intensity communications level. This possibility is 
examined in the next section. 

B. SPECIAL CASE ANALYSIS 

Each battalion headquarters in the scenario is dealing with a higher headquarters 
and three subordinate units. It is not unrealistic to believe that in high an intensity period 
of combat that the battalion headquarters will be the limiting nodes, rather than the relay 
sites. The battalion headquarters are dealing with frequent and urgent exchanges of 
information between themselves and three subordinate units, as well as equally frequent 
and urgent exchanges with the regimental headquarters. On the other hand, the relay sites 
are only handling the traffic between battalion and regimental headquarters and are not 
producing any bandwidth-reducing messages of their own. Once the battalion 
headquarters is saturated, the Penalty Function climbs, regardless of the performance of 
the relay suites. This may be a case of the simulation accurately modeling the system 
under study, despite the original expectations of the modeler. 

An analytical examination of the normal scenario is not possible; but in a special 
case, the nature of the arrival processes can be exploited to gain some insight into the 
relative traffic load at specific nodes in the network. This case is the one in which the 
probability that a unit (other than 8 th Marines) sends a message to its own higher 
headquarters is 1.0. This probability was set to .5 for all units except 8 th Marines for the 
basic scenario, and is changed here for purposes of analysis. 8 th Marines continues to 
send messages to any member of the network with equal probability. 

A further simplification made for purposes of analysis is that each element sends 
messages along the correct edge for it to reach its target. This is not how the model 
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works, but will provide for ease of analysis. Figure 16 is the approximate topology of the 
network when the battle at OBJ B is underway. Arrows indicate the flow of messages as 
required by the 100% -to-headquarters rule. Note that 1/8 and its subordinate units are all 
in range of Relay 1 02. 

We will examine the relative loads on 1/8 and Relay 102. Because 1/8 is in 
combat, intensity is set to high for 1/8 and 8 th Marines. No messages from 2TkBn or 2/8 
will reach Relay 102 or 1/8, because they will all be sent to a battalion headquarters or 
the 8 th Marines. 

The interarrival times for high communications intensity are: .3, .6, 6.0 (minutes) 
for high, mid, and low priority messages. We will aggregate all messages into a single 
arrival rate. The arrival rate of the Poison process is 1 /(interarrival time). That means 
that we can expect each non-relay JTRS to produce: 

60(l/.3 + 1/.6+1/6.0) = 310 messages per hour 




Figure 16. Network topology during the battle for OBJ B. 



8 th Marines will pick message targets at random, with probability 1/3 that it will 
send a message in the direction of 2/8 (4/12 possible targets in that direction). 1/4 of the 
messages from 8 th Marines will be for First Battalion, 8 th Marines, for a cumulative 
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fraction of 1/12 of the messages from 8 th Marines expected to be sent through Relay 102 
to 1/8. 

Relay 102 will also have 100% of the messages from 1/8 sent through itself on 
their way to 8 th Marines. The expected total load on Relay 102 will be 335.8 messages 
per hour (13/12 * 310). 

1/8 produces its own 310 messages per hour on average. It is also the target of 
100% of all three subordinate units’ traffic (an expected additional 930 messages per 
hour). Add to this the 310/12 messages expected to arrive from 8th Marines and the total 
expected load for 1/8 is 1265.8 messages per hour. This is over 3.7 times the load on 
Relay 102. 

This example gives some insight into why the model is behaving as it is. The 
bandwidth limiting element of the network is not the relay, it is the battalion 
headquarters. 
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VI. CONCLUSION AND RECOMMENDATIONS 



This thesis set out to examine the effects of changing relay suite bandwidth in a 
JTRS network. A discrete-event simulation model was developed to model the system 
and was implemented in Java using Simkit. The results of the simulation indicate that the 
JTRS network performance, as measured by timely arrival of messages, is insensitive to 
even large changes in relay suite bandwidth. 

The simulation model produced for this thesis has been demonstrated and has 
performed correctly in those cases tested. Correctly, in the case of the model’s 
performance, means only that the model functioned as designed, not that it was a perfect 
representation of the as-yet-nonexistent JTRS communication network. This thesis has 
built a base upon which further improvements can be built. 

Time did not permit the author to make all of the enhancements to the model that 
had originally been planned. Several key areas for further research are message routing 
schemes, different abstractions of bandwidth utilization, and implementation of terrain 
effects modeling. 

Messages are currently randomly routed to a member of the sender’s commList. 
The only firm restriction to this is that a message will not be routed back to the entity that 
sent it to the current holder. This prevents “ping-ponging” of messages back and forth 
between two entities in communication with each other but who are in communication 
with no other entities. However, messages tend to spend extra time in the system due to 
the simplicity of the routing system. A smarter implementation might be to poll members 
of the commList to determine if any of them have the messages recipient on their own 
commList. In this case the message would be sent to the first member reporting 
communication with the recipient. Alternatively, a shortest path algorithm could be 
implemented to pick the best feasible route from sender to target. 

Bandwidth utilization in this model is purely a function of message size. The 
message takes up a portion of the JTRS’s bandwidth proportional to its size and keeps 
that bandwidth tied up for a time also proportional to the message’s size. For example, a 
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message of size .1 (or 10% of a JTRS bandwidth), will take 10% of the sender’s 
bandwidth for .1 minute, likewise as message of size .2 will take 20% for .2 minutes. No 
matter whether the JTRS has 100% of its bandwidth available or only 20%, the message 
takes the same amount of time to transmit. A scheme could be developed to treat 
bandwidth in a way that reduces the time spent in message transmission if the JTRS has 
additional bandwidth available. This could easily be accomplished by assigning each 
message a weight base on the its size and assigning each radio a maximum weight 
capacity per time period. This suggested method is similar to, but simpler to implement 
than, the packet system of data transmission, in which every message is broken down into 
like sized packets that are then individually routed to the target. 

A last major enhancement is the introduction of terrain effects. The model 
currently does not take terrain in to account when determining the commList. Instead, 
the cookie cutter approach is taken: if another unit is with the user selected radio range, 
then that unit is added to the commList. This does not model the effects of terrain on 
radio wave propagation, which can and do cause very large variations from nominal radio 
ranges. 

The single major recommendation is one that was identified early in the research 
for this thesis. This recommendation is that the Marine Corps take steps to capture its 
actual bandwidth requirements and usage. This needs to be done in order to properly 
apply the power of modeling and simulation to our C4I architecture, and to ensure we 
procure C4I systems that will serve our needs into the future. Data on the frequency of 
occurrence of messages and the size of those messages is a critical first step in 
determining what the C4I architecture of the future needs to be able to do. 

In conclusion, this model helped to gain insight into a JTRS network by giving 
unexpected and counter-intuitive results, which in turn caused a deeper examination of 
the system under study. Upon further examination, these results make sense and are the 
valid results of the model, rather than of logical or syntactical errors in the programming. 
The implication of the results of this thesis is that the battalion headquarters are the 
bandwidth bottlenecks in the network. It is, therefore, at the battalion level that 
bandwidth should be increased in order to improve network performance. 
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APPENDIX A. JAVA CLASSES DEVELOPED FOR THIS THESIS 



1. CommMover. This class extends the BasicMover of Simkit. Moves a JTRS and can 
report which particular JTRS it is associated with. 

2. CombatManager: This class controls the changes in unit speed and communication 
intensity throughout the scenario. 

3. CommLinkMediator: Extends the CookieCutterMediator. Modifies the 
CookieCutterMediator to allow sensors to have a reference to the target, instead of a 
surrogate. This removes the information hiding feature of the CookieCutterMediator, but 
allows the JTRS to keep a CommList. 

4. JTRS: This class is the heart of the model. Each instance creates its own 
ArrivalProcesses, QueueManger, Receiver, and Transmitter. 

5. Message: This class keeps track of its own size, transmission time, target, sender, and 
the JTRS that most recently transmitted it. Messages are the objects passed around the 
network. 

6. MessageComparator: This class sorts Messages for the QueueManager, ensuring 
that Messages are put in the proper queue position. 

7. PenaltyCalc: This class listens to all Receivers to hear Message arrivals. Tracks the 
number of late Messages of each priority and returns the Penalty Function value when 
asked. 

8. QueueManager: This class puts Messages on, and removes Messages from the 
Queue. Sends Messages to the receiver when bandwidth is available. Receives 
generated Messages from the JTRS and received Messages from the Receiver. 

9. Receiver: This class listens to all Transmitters on the JTRS commList and receives 
Messages intended for its JTRS. 

1 0. TestScenario: This is the test program that makes that sets up and runs the 
simulation of the scenario. 

11. Transmitter: This class is responsible for picking a member of the commList and 
then sending the Message to that member. Receives Messages for transmission from the 
QueueManager. 
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